The Internet has become a backbone of communication with a vast repository of information available in various formats. Many companies are developing various applications for use on the Internet to facilitate real-time decision-making processes (e.g., transactional applications). In general these remote applications encompass any bi-directional or unidirectional access of remote data.
The full potential of the Internet for such purposes remains unfulfilled due to problems with its performance and reliability. One of the Internet's performance limitations in particular is the bandwidth problem. Modern remote applications require the transmission of a great deal of information at a high rate. When such applications are used over low-bandwidth data transmission media, such as typical telephone lines, the applications may not function properly and/or may result in lengthy wait times. This problem is also evident in high-bandwidth environments supporting many users (i.e., having a low bandwidth-to-user ratio). For purposes of this disclosure, the term “low bandwidth will refer to actual low bandwidth or a low bandwidth/user ratio. Bottlenecks may be caused by a low bandwidth/user connection, the infrastructure of the Internet Service Provider (ISP), the gateway to the Internet backbone, or the content provider's Web server and/or application server. Eliminating these problems may be prohibitively expensive or impractical. For example, not only is increasing bandwidth expensive, but it may not be practically possible in some areas that lack the infrastructure to do so.
The increasing bandwidth requirements are due to the increasing complexity of the data transmitted and to how the Internet exchanges information. The Internet may typically use hypertext mark-up language (HTML) and its related formats such as extensible mark-up language (XML), dynamic HTML (DHTML). The Internet also may use Hyper Text Transfer Protocol (HTTP), File Transfer Protocol (FTP), and other associated Transmission Control Protocol/Internet Protocol (TCP/IP) based communications protocols.
HTML defines the syntax and placement of special, embedded, directions that instruct a web browser on how to display the contents of a document which is made up of one or more HTML text files or associated media files, or other embedded files of any number of formats including text, images, and other support media. HTML instructs a web browser client application on how to make a document interactive through special hypertext links or through embedded programs like Java applets, which connect a document with other documents, as well as with other Internet resources. In addition, embedded programs can and often do contain their own interactive logic in the form of executable code and the associated resources.
A server digital processing system (server DPS) typically runs a web server and/or application server program to make documents, typically hypertext documents in the HTML language, available. Web servers and/or application servers typically have a standard interface for running external programs, such as Common Gateway Interface (CGI), Java servlets, Java server pages (JSPs) and Active server pages (ASPs) or other server-side solutions. Such programs handle incoming information requests and return the appropriate document or generate a document dynamically. For example, a gateway might receive queries, determine a response, and translate the response into a page of HTML so that the server DPS can send the result to a client digital processing system (client DPS). The client DPS typically runs a web browser (a program to allow retrieval and display of information from the server DPS). Server-side technologies such as JSP and ASP employ scripting engines or Java that process commands written in a scripting language or Java.
The web server and/or application server and the web browser communicate using HTTP. In HTTP, the web browser establishes a connection to a web server and/or application server and sends an HTTP request message to the server DPS. In response, the web server and/or application server checks for authorization, performs any requested action and returns an HTTP response message containing an HTML document resulting from the requested action, or an error message. The web server and/or application server then retrieves the document and returns it in an HTTP response message to the Web browser.
The client DPS may petition the server DPS for access to an application document, for example a transactional application form. The client DPS's petition causes the entire form to be constructed on the server DPS. The form is then packaged and transmitted to the client DPS. Typically the client DPS receives the HTML code and parses and renders the form at the client DPS.
FIG. 1 illustrates a process in which a client DPS requests and receives a remote application form from a server DPS in accordance with the prior art. Process 100, shown in FIG. 1, begins at operation 105 in which the client DPS requests access to a remote application form. The request (petition) may be made, from the client DPS to the server DPS, in a variety of ways including via Internet, Intranet, Extranet, local area networks (LANs), wide area networks (WANs), as well as others, and combinations thereof. For convenience the data transmission path between the client DPS and sever DPS is referred to as the “cloud”. The transmission of the petition through the cloud is limited by available bandwidth. Because the petition is typically only a small amount of data, this bottleneck may not cause significant delay.
At operation 110 the server DPS receives the petition. The petition is received by the web server/application server of the server DPS.
At operation 115 the server DPS determines whether the petition is for a standard interface file (for purposes of this illustration a JSP file). If the petition is a JSP file, at operation 116, the server performs a JSP processing operation. The JSP file is retrieved and passed to the servlet engine. If the JSP has not been previously instantiated, the servlet engine parses the JSP file and generates servlet source code. The servlet engine then compiles the source code and instantiates the servlet. At operation 117 the servlet then outputs standard HTML code.
If at operation 115 the petition is not a JSP file, the server DPS obtains the HTML code from the virtual directory at operation 118.
At operation 120 the HTML code (from the JSP servlet or from the virtual directory) is transmitted from the server DPS, through the cloud, to the client DPS. This HTML code is fairly heavy and may cause lengthy delay in the transmission especially for low bandwidth/user environments.
At operation 125 the client DPS receives the HTML code. The HTML code is received at the client DPS browser and may be buffered prior to being parsed and rendered. This buffering adds to the delay in presenting the remote application form.
At operation 130, after all of the transmitted code has been parsed and rendered, the remote application form presentation is complete on the client DPS.
Due to how HTML is structured, much of the code transmitted in such a scheme is related to the formatting structure of the document. This amounts to a tremendous amount of transmitted data that does not provide user-specific benefit. This situation has been addressed in several ways with varying degrees of success. For example, to avoid transmitting a document to the client DPS each time, terminal servers emulate a screen at the client DPS. This opens a client session on the server DPS where the application is actually running on the server DPS and only screen emulations are transmitted to the client DPS. That is, none of the presentation code or logic of a typical web-page transmission is included. The client DPS has an application emulator and is transmitting only interaction with the form (i.e., typed input and/or mouse movement). With terminal servers, various algorithms are used to reduce the required data transmission. Terminal servers allow for reduced processing power on the client DPS, but processing requirements are dramatically increased on the server DPS. Such schemes do not provide significant relief for very low bandwidth/user media such as typical (analog) telephone lines and have numerous other drawbacks. One such drawback is that the initial setup may require data transmission on the order of several megabytes (MB) which is installed at the client DPS as a plug-in, an object, or directly to the client DPS hard disk (i.e., not to the browser cache). This installation is, therefore, across a secure barrier. Such installation requires explicit user permission, alters the configuration of the client DPS, and produces a possibility of conflict and the perception of vulnerability to corruption. Additionally, terminal servers are system specific. That is, because an installation on the client DPS is required, terminal servers are not system independent. Moreover, where a user lacks administrative rights to be able to install the initial components or the terminal server cannot pass through firewalls or proxies, the terminal server may be rendered unusable.
Another attempt to reduce the amount of required data transmission in transactional application forms are installation schemes that create an environment on the client DPS to alter interaction with the server DPS. An example of such is the Java Virtual Machine (JVM), which is a self-contained operating environment to run Java applets. The idea behind the JVM is to install an environment on the client DPS that is operating system and browser independent. This has the potential of being able to reduce data transmission, because it may reduce the need to continually transmit document-structuring code.
However, JVM also has the drawbacks of the terminal server in that an initial installation is required. For JVM this may be as large as 11 MB because JVM requires objects and extra classes. JVM not only installs its overall environment, but each application requires its own specific environment (i.e., requests additional classes from the server). Because more data has to be accessed, the applications are sluggish. Moreover, JVM requires substantially more client DPS processing power. JVM may work well for small, specifically focused, applications but, in general, JVM still requires so much code that it does not significantly reduce the amount of required data transmission for transactional application forms.
Another example of the excessive amount of data transmitted via the cloud for remote application forms is the submission and data validation process. Many remote applications require that user input data be validated by the server DPS. Typically the user must submit the completed form and the server DPS must receive the completed form prior to attempting to validate specific inputs. If there was an error in completing the form, the entire page creation process must be employed to recreate the page adding values to fields and error messages where appropriate. If no error is detected in the user input data, the server DPS creates a page containing the validated information. This page is then transmitted to the client DPS via the cloud, for user verification. If the user submits the form with verification, the corresponding database process and other tasks may proceed. If the user is unable to verify the data, the page creation process must be employed as described above. This process not only requires a substantial amount of data transmission via the cloud, but also results in significant wait-time as pages are transmitted and/or recreated due to erroneous input.
Another disadvantage of typical remote applications is that they are typically poorly presented. This “look and feel” or user friendliness aspect is related to the fact that typical remote applications operate in batch mode and cannot interact with the server in real time. Typically the forms are quite long, causing the user to have to scroll, and provide no feedback from the server until the form is complete. Typical remote applications cannot operate in “chatty” mode as the continual process of closing, transmitting, and reopening the page would cause a delayed and disconcerted presentation.
What is needed is an effective system and method for reducing data transmissions between the client DPS and the server DPS via the cloud. Such data transmissions may include the transmission of data files or a collection of data files, including the transmission of text, audio, media, embedded programs, executable code, or other data that is published at a host server DPS. Such a system should reduce data transmission during accessing and presentation of remote application forms as well as for submission and data validation.
Preferably such a system should not require installation on the client DPS (i.e., would employ zero-install technology) and should not modify the secure side of the client DPS. Such a system should also pass through proxies and firewalls. Moreover, such a system should provide a user-friendly interaction (e.g., graphical user interface and “chatty mode”) for remote applications.
The need for such a system is most apparent where client DPS is accessing moderate to high-bandwidth data applications via low bandwidth/user media, though such a system should augment any bandwidth capacity.